The present invention relates in general to cryptographic processing systems and, more particularly, to a single-pass architecture and pipelining approach for a cryptographic processing core.
The rapid growth in Internet usage has increased the dependency on information stored and communicated by businesses and individuals. In particular, growth in DSL and cable modem usage by consumers and businesses and increased business-to-business Internet activity such as supply chain management have contributed to this dependency. As the desire for confidentiality, authenticity, and integrity increases, an increasing proportion of this information is sent in secure or encrypted form. Also, as the fiber-optic Internet infrastructure is built to replace older copper-wire or other existing infrastructure, an increasing proportion of Internet communication will occur at giga-bit per second speeds.
Internet communication uses two dominant standard security schemes: IP Security (IPSec) and Secure Sockets Layer (SSL). IPSec is a security protocol from the Internet Engineering Task Force (IETF) that provides authentication and encryption over the Internet. IPSEC is used to secure transmissions in virtual private networks (VPNs), which are used, for example, to connect remote clients within a corporation's intranet or for managing supply chain extranet procurement services between remote servers. It is currently anticipated that encryption processing will increasingly become one of the significant bandwidth bottlenecks in VPNs.
SSL is the leading security protocol on the Internet. When an SSL session is started between a server and a client computer running a browser, the server sends its public key to the browser, which the browser uses to send a randomly-generated secret key back to the server in order to set up a secret key exchange for the session. SSL is incorporated within most Internet browsers, such as the Internet Explorer browser from Microsoft Corporation, to secure financial or other transactions among businesses and consumers. Data-farm and web-hosting businesses are typical users of SSL communications, and improved SSL processing capacity would increase the number of secure transactions that such businesses could support.
Secure communications are desirable for sensitive activities like on-line financial transactions or the transmission of personal medical information, but can require significantly increased processing demands at both ends of a communications session. This processing demand is further increased by the migration to a fiber optic Internet infrastructure, which provides significantly higher communication bandwidth and increases the volume of data for security processing. As the demand for secure Internet communication increases, security processing needs consume ever increasing proportions of the available central processing capability of communications network servers.
Internet communication, including secure communication, is accomplished using standard data packet transmission protocols such as the Internet Protocol (IP). IP communication servers encrypt/decrypt and sign/authenticate inbound and outbound data packets to accomplish typical IP communication. Existing data security and acceleration co-processors work with network server or host central processors to share some of the cryptographic processing load such as, for example, the encrypting, decrypting and authenticating of data packets. However, existing co-processors have several limitations.
First, existing security co-processors handle only one channel of IP packet data, do not support packet pipelining, and do not provide simultaneous support on the same chip for both the IPSec and SSL protocols for several of the most commonly-used encryption and hash algorithms. The foregoing limitations reduce the throughput and efficiency of the co-processor because, without pipelining, portions of the co-processor chip will not be fully utilized for significant time periods. In addition, the lack of multi-channel support limits the modularity and scalability of the co-processor. Further, the lack of support of multiple encryption and hash algorithms requires that the server processor handle the security processing for those packets using encryption or hash protocols not supported by the coprocessor. This may place significant packet handling duties on the server processor. For example, existing co-processors do not support both of the widely-used advanced encryption standard (AES) and ARCFOUR encryption algorithms. Accordingly, it is necessary to use more than one security co-processor to handle secure traffic that is expected to regularly use AES and ARCFOUR encryption.
Existing security co-processors also do not provide local access to different records of security association data that can be selected based on the security protocol for the currently-processed data packet. The security association data includes, among other items, the encryption keys necessary for cipher operations. Thus, the server or host processor must use host bus bandwidth to transfer security association data to the coprocessor as required for processing data packets.
Another limitation of existing co-processors is that they do not exhibit packet intelligence. In other words, the co-processor is not able to locally vary the security handling of the packet data as appropriate for different security protocols. Instead, the host processor must handle items specific to a particular security protocol such as, for example, the insertion of cipher block padding and Message Authentication Code (MAC) appending for outbound data packets.
An additional limitation of existing co-processors is the use of only a single local packet data memory such as, for example, a single FIFO memory. In some cases, the single memory will become a bottleneck to high security processing throughput because the processing speeds of cipher algorithms have not kept pace with the recent, sudden increase in packet throughput requirements. Further, more than one read access of packet data from the single memory will be required for those security protocols that require the hashing-of packet data prior to cipher operations—once for the cipher operation and once to obtain clear data for the hash operation. Moreover, packet data that does not require cipher or hash operations must be read from the single memory after other packet data has completed cipher and/or hash processing because packets are processed one packet at a time.
Hence, there is a need for a cryptographic processor that uses multiple independent packet processing channels, supports both the IPSec and SSL protocols and the most common encryption and hash algorithms on the same chip, and supports packet pipelining for efficient use of the processor. There is a further need for a processor that provides local access to security association data to better use the bus bandwidth between the host processor and the cryptographic processor. Also, there is a need for the processor to recognize the security protocol associated with incoming data packets and to handle certain protocol-specific operations locally on the processor chip without the need for intervention by the host processor. Additionally, there is a need for a processor that reduces local memory bottlenecks associated with existing single memory designs. The processor should accomplish the foregoing while providing improved network transparency (so that, for example, network processors can handle the most common security protocols without additional special processing requirements), maintaining optical-data line transmission rates, and exhibiting improved scalability and compatibility with evolving fiber optic security standards.